A Type Checker for a Logical Framework with Union and Intersection Types

We present the syntax, semantics, and typing rules of Bull, a prototype theorem prover based on the Delta-Framework, i.e. a fully-typed lambda-calculus decorated with union and intersection types, as described in previous papers by the authors. Bull also implements a subtyping algorithm for the Type Theory Xi of Barbanera-Dezani-de'Liguoro. Bull has a command-line interface where the user can declare axioms, terms, and perform computations and some basic terminal-style features like error pretty-printing, subexpressions highlighting, and file loading. Moreover, it can typecheck a proof or normalize it. These terms can be incomplete, therefore the typechecking algorithm uses unification to try to construct the missing subterms. Bull uses the syntax of Berardi's Pure Type Systems to improve the compactness and the modularity of the kernel. Abstract and concrete syntax are mostly aligned and similar to the concrete syntax of Coq. Bull uses a higher-order unification algorithm for terms, while typechecking and partial type inference are done by a bidirectional refinement algorithm, similar to the one found in Matita and Beluga. The refinement can be split into two parts: the essence refinement and the typing refinement. Binders are implemented using commonly-used de Bruijn indices. We have defined a concrete language syntax that will allow the user to write Delta-terms. We have defined the reduction rules and an evaluator. We have implemented from scratch a refiner which does partial typechecking and type reconstruction. We have experimented Bull with classical examples of the intersection and union literature, such as the ones formalized by Pfenning with his Refinement Types in LF. We hope that this research vein could be useful to experiment, in a proof theoretical setting, forms of polymorphism alternatives to Girard's parametric one

Logical Networks: Self-organizing Overlay Networks and Overlay Computing Systems: [EPI Proposal V2.0]

Contents 1 Team on March 15, 2010 ...........................................42 Capsule ...........................................52.1 Slogan and logo............................................ 5 2.2 One equation fits all and keywords ................................. 6 2.3 How to read this proposal ...................................... 63 Vertical view ...........................................63.1 Panorama............................................... 6 3.2 General definitions .......................................... 8 3.3 Virtual organization ......................................... 9 3.4 Execution model ........................................... 94 Horizontal view ...............................................94.1 Panorama............................................... 94.2 Arigatoni overlay network ...................................... 10 4.2.1 Arigatoni units........................................ 10 4.2.2 Virtual organizations in Arigatoni ............................. 12 4.2.3 Resource discovery protocol (RDP)............................. 12 4.2.4 Virtual Intermittent Protocol (VIP) ............................ 13 4.2.5 iNeu: librairies for network computing........................... 144.3 Babelchord, a DHT’s tower ..................................... 144.4 Synapse,interconnecting heterogeneous overlay networks. . . . . . . . . . . . . . . . . . . . . 154.5 Cross-layer overlay design for geo-sensible applications . . . . . . . . . . . . . . . . . . . . . . 175 Diagonal view...............................................175.1 Panorama............................................... 17 5.2 Trees versus graphs: a conflict without a cause .......................... 17 5.3 Fault tolerance ............................................ 18 5.4 Parametricity and universality ................................... 18 5.5 Social networking........................................... 19 5.6 Choice of development platform................................... 19 5.7 Quality metrics for an overlay computer .............................. 19 5.8 Trust and security .......................................... 20 5.9 New models of computations .................................... 216 Topics and time line...............................................226.1 Panorama............................................... 226.2 Topicview............................................... 22 6.2.1 Vertical issues......................................... 22 6.2.2 Horizontal issues ....................................... 22 6.2.3 Diagonalissues........................................ 236.3 Timeview............................................... 23 6.3.1 Short-term .......................................... 23 6.3.2 Medium-term......................................... 24 6.3.3 Long-term........................................... 247 Potential application domains ...........................................247.1 Panorama............................................... 24 7.2 P2P social networks ......................................... 25 7.3 Overlay computer for mobile ad hoc networks........................... 25 7.4 OverStic: the mesh overlay network in Sophia Antipolis ..................... 27 7.5 Reducing the Digital Divide..................................... 28 7.6 GRID applications: scenario for seismic monitoring ....................... 29 7.7 Interconnection of heterogeneous overlay networks ........................ 30 7.8 Toward an overlay network of things (RFID) ........................... 318 Software ...........................................328.1 Panorama............................................... 328.2 Prototype software.......................................... 32 8.2.1 Arigatoni simulator ..................................... 32 8.2.2 Ariwheels........................................... 32 8.2.3 BabelChord.......................................... 36 8.2.4 Synapse............................................ 37 8.2.5 Open-Synapse Client..................................... 38 8.2.6 myTransport Gui....................................... 39 8.2.7 CarPal: a P2P carpooling service ............................. 39 8.2.8 Husky interpreter....................................... 408.3 Potential software .......................................... 41 8.3.1 myMed (in french), see http://www-sop.inria.fr/mymed . . . . . . . . . . . . . . . . 419 Contracts...........................................439.1 INTERREG Alcotra: myMed,2010-2013.............................. 43 9.2 COLOR:JMED,2010 ........................................ 43 9.3 FP6 FET GlobalComputing: IST AEOLUS, 2006-2010 ..................... 43 9.4 JET TEMPUS DEUKS, 2007-2009................................. 4410 Collaborations ...........................................4411 Self assessment ...........................................4411.1 Trivia ................................................. 45 11.2 Conclusions.............................................. 45We propose foundations for generic overlay networks and overlay computing systems. Such overlays are built over a large number of distributed computational agents, virtually organized in colonies or virtual organizations, and ruled by a leader (broker) who is elected democratically (vox populi, vox dei) or imposed by system administrators (primus inter pares). Every agent asks the broker to log in the colony by declaring the resources that can be offered (with variable guarantees). Once logged in, an agent can ask the broker for other resources. Colonies can recursively be considered as evolved agents who can log in an outermost colony governed by another super-leader. Communications and routing intra-colonies goes through a broker-2-broker PKI-based negotiation. Every broker routes intra- and inter- service requests by filtering its resource routing table, and then forwarding the request first inside its colony, and second outside, via the proper super-leader (thus applying an endogenous-first-estrogen- last strategy). Theoretically, queries are formulæ in first-order logic equipped with a small program used to orchestrate and synchronize atomic formulæ (atomic services). When the client agent receives notification of all (or part of) the requested resources, then the real resource exchange is performed directly by the server(s) agents, without any further mediation of the broker, in a pure peer-to-peer fashion. The proposed overlay promotes an intermittent participation in the colony, since peers can appear, disappear, and organize themselves dynamically. This implies that the routing process may lead to failures, because some agents have quit or are temporarily unavailable, or they were logged out manu militari by the broker due to their poor performance or greediness. We aim to design, validate through simulation, and implement these foundations in an overlay network computer system. (From [Liquori-Cosnard TGC-07 paper])

Peter, le langage qui n’existe pas...

“Inside every large language is a small language struggling to get out ...” [Igarashi et al. 2001]“... and inside every small language is a sharp extension looking for better expressivity ...” [Liquori & Spiwack 2008]It is my privilege and pleasure to introduce Peter, the language that does not exist... The Peter language contains almost the linguistic features I have introduced and investigated in the field of functional and object-oriented programming, plus some new features not published yet. In Peter’s Habilitation, I will try to limit as much as possible the mathematical overhead and the technicalities (e.g. full set of rules, full proofs of theorems, etc.). In my opinion, the habilitation thesis should not be a mere translation of the candidate’s most successful papers (3), nor a commented curriculum vitæ, nor a survey of all the related works in his scientific area (4), just to mention a few “classic Habilitation styles”. It is my opinion that it should be short in length since it is experienced that a very few Habilitation thesis are really downloaded, cited and read. Oftenly, habilitation thesis are not even made accessible on the Web. Peter’s Habilitation will be based on the following three points: • (Modularity) I will present a (Turing complete) kernel of Peter, called Baby Peter, and I will continue in the rest of the Habilitation to extend it in a modular fashion until the final extension, called Wise Peter. Baby Peter is a functional language with object-oriented features equipped with a sound type system. Peter bears some similarities to Atsushi, Benjamin and Phil’s Featherweight Java [IPW01] and Alonso Church’s typed lambda calculus [Chu41]. The main difference lies in an ad hoc exception-handling mechanism allowing the programmer to choose the type system according to her/his necessities and goals. Even more, it allows the programmer to write her/his own type system (see item (Type-programmable)). Some chapters will focus on operational semantics, some others on type systems, some others on both. All topics will be treated in a “lightweight fashion”. Examples of extensions are for instance mixing class-based and pure object-based features, but also improving proof languages à la LF with pattern matching facilities and including those metalanguages to Peter in order to mix algorithms and their correctness proofs. • (Verbatim-like) Instead of annoying the reader with a plain French translation of some of my most relevant papers (6), I will show, for each extension, only some key rules of the operational semantics or of the type system (every system has at least a key rule...) and some motivating examples. I do not plan to prove type soundness for each extension of Peter: the whole soundness of Wise Peter is left as a challenge for the “next” user friendly proof assistant.• (Type-programmable) Type systems for programming languages and proof languages are fixed a priori by language designers; type systems are not first class citizens. To my little knowledge, no language allows the programmer to build, choose, or mix type systems. The idea of modifying the type discipline at compile time is not completely new; a quite inspiring work has been done by the “visionary-6-pages” paper by Gilad in 2004 [Bra04] called Pluggable Type Systems. The possibility to mixing type systems and using it as a first class citizens is an interesting research strand that will constitute an original contribution in Peter’s Habilitation. With the intention of disseminating science in a simple, clear and pedagogical way, and inspired by the works of Kim [Bru99, TKB01, BDKT03, RBC+ 05, Bru02] and Gilles [Dow03, Dow07], I wish you a very nice reading of the Peter’s Habilitation. 3 Although certain parts are taken of my articles. 4 The typographic convention is that references to my papers are in “numeric” style while references to other papers are in “alphanumeric” style. 6 We provide a CD and a Web site with all my papers.C’est mon privilege et plaisir d’introduire Peter, le langage qui n’existe pas... Le langage Peter contient quasiment tous les aspects linguistiques que j’ai introduits et étudiés dans le domaine de la programmation fonctionnelle et objets, ainsi que quelques idées qui n’ont pas encore été publiées. Dans l’habilitation de Peter, la démarche que je suivrai consiste à essayer de limiter les détails concernant les aspects théoriques et techniques (c-à-d. les ensembles complets des règles de typage, suites de théorèmes abscons, etc.). Mon mémoire d’habilitation ne sera pas une traduction brutale des différents articles publiés (1), ni un curriculum vitæ commenté, ni un panorama de tous les articles dans un domaine scientifique (2), pour ne citer que quelques styles classiques de thèses d’habilitation. Tout d’abord elle sera courte car l’expérience enseigne que très peu de thèses d’habilitation sont réellement téléchargées, citées et lues. Très souvent, les thèses d’habilitation ne sont même pas accessibles sur le Web. L’Habilitation de Peter sera fondée sur les trois « dogmes » suivants: • (Modularité) Je commencerai par le plus petit fragment complet (au sens de Turing) de Peter, appelée Baby Peter et je continuerai de façon modulaire, d’extension en extension, jusqu’à l’extension finale appelée Sage Peter. Baby Peter est un langage fonctionnel avec des constructions linguistiques orientées objet et un système de types correct. Peter partage quelques similitudes avec Featherweight Java de Atsushi, Benjamin et Phil [IPW01] et le lambda calcul typé de Alonso (Church) [Chu41]. La différence principale entre Featherweight Java et Peter, est un mécanisme d’exceptions ad hoc, qui permet au programmeur de décider quel système de types sera le plus adapté à l’egard de ses nécessités et objectifs. En plus, ce mécanisme permet au programmeur d'écrire son système de types (voir point Type-programmable). Certains chapitres seront focalisés sur un nouveau système de types, tandis que, dans d’autres chapitres, l’extension sera associée à une extension de la syntaxe et du système de types. Tous les arguments seront traités d’une façon accessible au plus grand nombre de lecteurs. Comme exemples d’extensions, je citerai une forme nouvelle d'héritage multiple, une extension de Peter qui permettra à un objet de « s'échapper de sa classe », une extension de Peter avec filtrage évolué et enfin une extension de Peter qui permettra de mélanger algorithmes et preuves de correction d’algorithmes.• (Verbatim-like) Plutôt que d'asséner à mes lecteurs une traduction française mot-à-mot de mes articles scientifiques (5), j’ai privilegié une présentation simple de chaque extension, utilisant uniquement quelques règles clés de la sémantique opérationnelle ou du système de types (il y a toujours une règle clé...), en ajoutant immédiatement des exemples pour motiver et comprendre son utilisation correcte. Je ne prouverai pas la propriété de complétude de chaque système de types qui étend Peter : la complétude de Sage Peter est proposée en défi au prochain assistant à la preuve convivial. • (Type-programmable) Les systèmes de types pour les langages de programmation et pour la preuve sont fixés a priori par leurs concepteurs et ne sont pas des objets de première classe pouvant être modifiés ou simplement utilisés par le programmeur qui en subit les qualités et les faiblesses. À ma connaissance, aucun langage ne permet au programmeur de « programmer » sa discipline de types personnelle. L’idée de modifier la discipline de typage à la compilation n’est pas très nouvelle ; un article « visionnaire » de 6 pages, qui m'a eclairé, a été Pluggable Type System de Gilad [Bra04] sorti en 2004. La possibilité de permettre au programmeur d'écrire sa propre discipline de typage et de l’utiliser à la volée est par elle-même une contribution originale dans l’habilitation de Peter. Avec l’envie de diffuser la connaissance scientifique de façon simple, claire et pédagogique, inspiré par les ouvrages de Kim [Bru99,TKB01, BDKT03, RBC+ 05, Bru02] et Gilles [Dow03, Dow07], il ne me reste plus qu'à vous souhaiter une bonne lecture de l’habilitation de Peter. 1. Bien que certaines parties soient tirées de mes articles. 2. La convention typographique est que les référence à mes articles soit en style « numérique » tandis que les références à d’autres articles soit en « alphanumérique ». 5 Un CD et un site web contiendront tous mes articles. <br

Improving Resource Discovery in the Arigatoni Overlay Network

International audienceArigatoni is a structured multi-layer overlay network providing various services with variable guarantees, and promoting an intermittent participation to the virtual organization where peers can appear, disappear and organize themselves dynamically. Arigatoni mainly concerns with how resources are declared and discovered in the overlay, allowing global computers to make a secure, PKI-based, use of global aggregated computational power, storage, information resources, etc. Arigatoni provides fully decentralized, asynchronous and scalable resource discovery, and provides mechanisms for dealing with dynamic virtual organizations. This paper introduces a non trivial improvement of the original resource discovery protocol by allowing to register and to ask for multiple instances. Simulations show that it is efficient and scalable

LogNet: Extending Internet with a Network Aware Discovery Service: [Extended abstract]

[Everything needs to change, so everything can stay the same, From “The Leopard” by Giuseppe Tomasi di Lampedusa] Internet in recent years has become a huge set of channels for content distribution. And this has highlighted limits and inefficiencies of the current protocol suite originally designed for host-to-host communication. This paper joins the research efforts addressed by the new Internet challenges by proposing LogNet, a conservative extension of the current TCP/IP hourglass Internet architecture, that provides a new network aware Content Discovery Service.Contents are referred via the new notion of HyperNames (HN), whose rich syntax allow to specify, hosts, pki, fingerprint and a large list of optional logical attributes (tags) attached to the content name, such as mutable vs immutable contents, digital signatures, ownership, availability, price, etc. HyperNames are in part human-readable and in part machine-readable and only in the latter case self-certifying.Publication and discovery of HN is achieved using the new distributed service Content Name System (CNS) with related protocol, whose behavior and architecture is, partly, inspired by the DNS, and whose “routing logic” uses the BGP inter domain routing information.The core of CNS is the HyperName Lookup Algorithm (HLA) which “tunes” content discovery of being network aware, by exploiting the Autonomous System (AS) relationships. In partic- ular, the HLA starts the content discovery process in the local AS (i.e., where the query starts), and in case of negative answer, propagate the query by accounting for the AS-to-AS relationships (i.e., peering, provider-to-customer, customer-to-provider). After discovered the owner(s) or the purveyor(s) of the content we are looking for, the latter can be retrieved using common transfer protocols (centralized or distributed), since the actors of this transfer are chosen in a network aware fashion (i.e., as close as possible one to each other)

Extending FeatherTrait Java with Interfaces

International audienceIn the context of Featherweight Java by Igarashi, Pierce, and Wadler, and its recent extension FeatherTrait Java (FTJ) by the authors, we investigate classes that can be extended with trait composition. A trait is a collection of methods, i.e. behaviors without state; it can be viewed as an "incomplete stateless class" ie, an interface with some already written behavior. Traits can be composed in any order, but only make sense when "imported" by a class that provides state variables and additional methods to disambiguate conflicting names arising between the imported traits. We introduce FeatherTrait Java with interfaces (iFTJ), where traits need to be typechecked only once, which is necessary for compiling them in isolation, and considering them as regular types, like Java-interfaces with a behavioral content

A Type Checker for a Logical Framework with Union and Intersection Types

International audienceWe present the syntax, semantics, typing, subtyping, unification, refinement, and REPL of Bull, a prototype theorem prover based on the ∆-Framework, i.e. a fully-typed Logical Framework à la Edinburgh LF decorated with union and intersection types, as described in previous papers by the authors. Bull also implements a subtyping algorithm for the Type Theory Ξ of Barbanera-Dezani-de'Liguoro. Bull has a command-line interface where the user can declare axioms, terms, and perform computations and some basic terminal-style features like error pretty-printing, subexpressions highlighting, and file loading. Moreover, it can typecheck a proof or normalize it. These terms can be incomplete, therefore the typechecking algorithm uses unification to try to construct the missing subterms. Bull uses the syntax of Berardi's Pure Type Systems to improve the compactness and the modularity of the kernel. Abstract and concrete syntax are mostly aligned and similar to the concrete syntax of Coq. Bull uses a higher-order unification algorithm for terms, while typechecking and partial type inference are done by a bidirectional refinement algorithm, similar to the one found in Matita and Beluga. The refinement can be split into two parts: the essence refinement and the typing refinement. Binders are implemented using commonly-used de Bruijn indices. We have defined a concrete language syntax that will allow user to write ∆-terms. We have defined the reduction rules and an evaluator. We have implemented from scratch a refiner which does partial typechecking and type reconstruction. We have experimented Bull with classical examples of the intersection and union literature, such as the ones formalized by Pfenning with his Refinement Types in LF and by Pierce. We hope that this research vein could be useful to experiment, in a proof theoretical setting, forms of polymorphism alternatives to Girard's parametric one

Featherweight-Trait Java : A Trait-based Extension for FJ

In the context of statically typed class-based languages, we investigate classes which might extend upon trait composition. Building classes by composing method-clusters is a well-known technique in implementing object- and class-based languages with simple inheritance, that has been explored in an untyped setting as a first-class mechanism available to the user only recently. This paper presents Featherweight-Trait Java (FTJ), a conservative extension of Featherweight Java (FJ), a simple light-weight class-based calculus take off with statically typed traits. In FTJ, classes can be built using traits as a basic behavioral brick; every trait contains only behavior and no state. Method conflicts between traits must be resolved explicitly by the user either (1) by aliasing or excluding method names, or (2) overriding explicitly in the class. A special emphasis has been put on dealing with "diamond'' conflict, a classical issue playing with multiple inheritance. That makes a kind of multiple inheritance not only possible but simple. As such, FTJ is as a proper extension of FJ. We present a new operational semantics with a new dynamic lookup algorithm, and a new sound type system that guarantees that evaluating a well-typed expression never yields a "message not understood'' run-time error nor get the interpreter stuck. We give an example which illustrates the increased expressive power of the typed trait-based (multiple inheritance) model of FTJ with respect to the classical (single inheritance) typed class-based one of FJ. The resulting calculus appears to be a good starting point for a rigorous mathematical analysis of typed trait-based languages, and a novel paradigm for typed trait-oriented programming

The Delta-calculus: syntax and types

International audienceWe present the $∆$-calculus, an explicitly typed $λ$-calculus with strong pairs, projections and explicit type coercions. The calculus can be parametrized with different intersection type theories T , e.g. the Coppo-Dezani, the Coppo-Dezani-Salle', the Coppo-Dezani-Venneri and the Barendregt-Coppo-Dezani ones, producing a family of $∆$-calculi with related intersection typed systems. We prove the main properties like Church-Rosser, unicity of type, subject reduction, strong normalization, decidability of type checking and type reconstruction. We state the relationship between the intersection type assignment systems a` la Curry and the corresponding intersection typed systems a` la Church by means of an essence function translating an explicitly typed $∆$-term into a pure $λ$-term one. We finally translate a $∆$-term with type coercions into an equivalent one without them; the translation is proved to be coherent because its essence is the identity. The generic $∆$- calculus can be parametrized to take into account other intersection type theories as the ones in the Barendregt et al. book